The booking journey 2: conversations between channels and engines Infographic
Booking Engine 12/11/2019
In The reservation journey 1: from Fax to XML 2.0 , the first article of the particular saga created by Nacho Marín, Lead Developer at Paraty Tech, concluded with great promise. This second installment aspires to fulfill it.
With The Booking Journey 2: Conversations between channels and engines , I have set out to resolve all those doubts that I receive daily in relation to the way in which channel managers and booking engines communicate. To do this, I have decided to unify them into two fundamental questions:
By answering them, I hope to also ultimately help you figure out which channel manager is best suited for your booking engine. The million dollar question...
That said, as a starting point, I think it is best to categorize each type of connection based on three fundamental aspects:
Infographic Paraty Tech, Channels Vs. Motors, Which one is best for you?
To be honest, the format of the files exchanged, as such, is unimportant when it comes to choosing one channel manager or another, since it is a purely IT factor. However, I do consider it important to explain what fundamental types of formats there are and how to interpret them, since many times you will find yourself included, in copy, in email chains in which these types of files travel, as attachments, and it is possible that the information contained therein is of interest to you.
Most channel managers share and receive information in what is known as an XML File . This file, although it may be visually unattractive, is relatively easy to understand by a human without programming knowledge. In addition, it has an advantage: browsers (Explorer, Chrome, Firefox, Safari, Opera, etc.) know how to read them, and will help you interpret them, coloring them and allowing you to open and close their elements.
Below I show you an example of a fragment of the typical XML File:
Another common format, which you have probably heard of despite being less common, is the JSON File , which would have a structure like the one shown below:
Another very interesting point, which you should take into consideration, is the one that concerns the communication that is established between the engines and the channel managers when the reservations are downloaded. Although it may not be decisive enough to determine the decision to opt for one supplier or another, it is essential to understand what two ways channel managers have to recover all the reservations made through the different online points of sale.
In this way, we will be able to distinguish where the problem has been when a reservation has taken longer than desired to dump or, in the worst case, has not even done so. Likewise, we will be more prepared to deal with the explanations provided, in this regard, by the different technical supports involved in the process in question.
So, from the engines' point of view, there are two ways to send reservations:
Sending Pull Reservations
When sending Pull type reservations, it is the channel manager who requests, every x minutes, the list of reservations made that day. This request is called a Pull Action.
In favor of this type of communication, it must be said that it is very difficult for a reservation not to be sent due to a specific failure (for example, a downed server), since the list of reservations is being requested throughout the day.
On the other hand, the download of reserves is not immediate. For example, if the channel manager requests them every 10 minutes, a reservation can take, at most, that time to be integrated.
Sending Push Reservations
Contrary to the behavior just described, in Push type reservation sending, reservations are sent immediately after being made, without waiting times, minimizing the probability of possible overbooking situations.
Using the server down hypothesis again, the main drawback of this type of communication is that, if a retry system is not configured, the reservation is somewhat more likely to be lost.
At Paraty Tech, if an error is recorded, we provide a solution to this type of incident by resending the reservation up to four times. If even after the fourth attempt we are not able to obtain the OK from the channel manager, we send alert emails so that the reservation can be managed manually.
Now, let's get right into what I consider the most important aspect when deciding on one or another channel manager. To do this, I will explain the two types of connection that exist, regarding the communication of the status of availability, restrictions and price. Once again, as almost always happens in life, each of them has its pros and cons. We thus enter the complex world of Channels Pull and Channels Push.
Channels Pull
This type of channel offers, in real time, prices and availability. That is, every time a search is carried out on a web page (for example, on the hotel's official sales channel), the search engine sends a request to the channel, and it responds with prices and availability.
These types of connections have the advantage that they are usually easier to configure, since all the product details are loaded into a single control panel. In theory, this should reduce the risk of errors with fewer systems involved. What's more, for this same reason, it should also be easier to locate an error, for example, when calculating a price.
But, sometimes, strengths can also be understood as weaknesses, and their main disadvantage derives, precisely, from their own nature: since everything is centralized in a single system (the channel), all the engines with which it is connected depend of the same.
Channel Pull is usually accompanied by slower searches, since the engine must first send a request (Request), then wait for the response (Response), and once obtained, process it to show it to the client.
Another very common problem with Channels Pull is the possible loss of availability status, and the reason is very simple. All it takes is for the channel's servers to go down, for it to stop offering availability on all the engines with which it is connected, without anyone being able to do anything at all about it.
Lastly, and in my opinion the most important disadvantage of Channels Pull is their lack of flexibility. The hotel will have no choice but to limit itself to the functionalities offered by the channel. That the channel does not accept the promocode option? Then it will be very difficult for your website's search engine to implement them. And so with everything.
Aspiring, as always, to continue building possible bridges of collaboration, something that involves trying to resolve limitations like the one we just described, at Paraty Tech we have developed an intermediate layer that intercepts the channel prices before displaying them, which allows us apply a different logic to them. Unfortunately, this is not always possible due to the security measures of this type of channels, which usually include a price check, and when submitting the reservation, it may be rejected if the price does not match. And even if this were not the case, the mere fact of having two logics loaded in different places increases the complexity of the system, something that clashes head-on with what constitutes the main strength of Channels Pull: its simplicity of configuration and simplicity of connection.
Channels Push
This type of channel keeps prices, restrictions, and availability up to date on the panels it connects to. Normally it communicates with the search engines every time there is a change (quota, price, etc.) or periodically, every certain time interval. That is, there are identical and parallel structures loaded in all systems that are interconnected.
For this reason, the different websites that are connected to a Channel Push will always offer availability, regardless of whether the channel may suffer a blackout, since the entire product will be preloaded (and updated until said blackout) in the other systems, that work independently of the channel.
Furthermore, the speed when it comes to showing availability on the different websites is much higher than that of Channels Pull, since it does not require any type of communication between both systems.
Finally, it will also offer greater flexibility, since having pre-loaded prices will allow you to incorporate sophisticated offers, create packages, use promo codes, implement rates with complicated structures, etc. All of this, whether the channel supports these functionalities or not.
But then, what are the drawbacks of a Channel Push? In short, fundamentally two. On the one hand, the initial configuration will involve more work due to the famous mappings, having parallel structures loaded on both sides, which requires a correlation between the different internal codes.
On the other hand, resolving incidents can be somewhat more tedious. Having prices loaded in multiple panels can make it difficult to pinpoint the exact point where the problem occurred by displaying the wrong price or wrong availability.
In this regard, and finally, at Paraty Tech we have implemented auditing software that allows us to recover the XML history sent by the Push Channels, and thus know the specific day and exact time in which we receive a price, restriction or quota.
With The Booking Journey 2: Conversations between channels and engines , I have set out to resolve all those doubts that I receive daily in relation to the way in which channel managers and booking engines communicate. To do this, I have decided to unify them into two fundamental questions:
- What variants of Channel Managers are available in the market?
- What advantages and disadvantages do they have?
By answering them, I hope to also ultimately help you figure out which channel manager is best suited for your booking engine. The million dollar question...
That said, as a starting point, I think it is best to categorize each type of connection based on three fundamental aspects:
- The format of the exchanged files
- The way reservations are downloaded
- The way prices and availability are exchanged
Infographic Paraty Tech, Channels Vs. Motors, Which one is best for you?
1. Channel managers based on the format of the files exchanged
To be honest, the format of the files exchanged, as such, is unimportant when it comes to choosing one channel manager or another, since it is a purely IT factor. However, I do consider it important to explain what fundamental types of formats there are and how to interpret them, since many times you will find yourself included, in copy, in email chains in which these types of files travel, as attachments, and it is possible that the information contained therein is of interest to you.
Most channel managers share and receive information in what is known as an XML File . This file, although it may be visually unattractive, is relatively easy to understand by a human without programming knowledge. In addition, it has an advantage: browsers (Explorer, Chrome, Firefox, Safari, Opera, etc.) know how to read them, and will help you interpret them, coloring them and allowing you to open and close their elements.
Below I show you an example of a fragment of the typical XML File:
Another common format, which you have probably heard of despite being less common, is the JSON File , which would have a structure like the one shown below:
2. Channel managers attending to the download of reservations
Another very interesting point, which you should take into consideration, is the one that concerns the communication that is established between the engines and the channel managers when the reservations are downloaded. Although it may not be decisive enough to determine the decision to opt for one supplier or another, it is essential to understand what two ways channel managers have to recover all the reservations made through the different online points of sale.
In this way, we will be able to distinguish where the problem has been when a reservation has taken longer than desired to dump or, in the worst case, has not even done so. Likewise, we will be more prepared to deal with the explanations provided, in this regard, by the different technical supports involved in the process in question.
So, from the engines' point of view, there are two ways to send reservations:
Sending Pull Reservations
When sending Pull type reservations, it is the channel manager who requests, every x minutes, the list of reservations made that day. This request is called a Pull Action.
In favor of this type of communication, it must be said that it is very difficult for a reservation not to be sent due to a specific failure (for example, a downed server), since the list of reservations is being requested throughout the day.
On the other hand, the download of reserves is not immediate. For example, if the channel manager requests them every 10 minutes, a reservation can take, at most, that time to be integrated.
Sending Push Reservations
Contrary to the behavior just described, in Push type reservation sending, reservations are sent immediately after being made, without waiting times, minimizing the probability of possible overbooking situations.
Using the server down hypothesis again, the main drawback of this type of communication is that, if a retry system is not configured, the reservation is somewhat more likely to be lost.
At Paraty Tech, if an error is recorded, we provide a solution to this type of incident by resending the reservation up to four times. If even after the fourth attempt we are not able to obtain the OK from the channel manager, we send alert emails so that the reservation can be managed manually.
3. Channel managers attending to the communication of availability and price
Now, let's get right into what I consider the most important aspect when deciding on one or another channel manager. To do this, I will explain the two types of connection that exist, regarding the communication of the status of availability, restrictions and price. Once again, as almost always happens in life, each of them has its pros and cons. We thus enter the complex world of Channels Pull and Channels Push.
Channels Pull
This type of channel offers, in real time, prices and availability. That is, every time a search is carried out on a web page (for example, on the hotel's official sales channel), the search engine sends a request to the channel, and it responds with prices and availability.
These types of connections have the advantage that they are usually easier to configure, since all the product details are loaded into a single control panel. In theory, this should reduce the risk of errors with fewer systems involved. What's more, for this same reason, it should also be easier to locate an error, for example, when calculating a price.
But, sometimes, strengths can also be understood as weaknesses, and their main disadvantage derives, precisely, from their own nature: since everything is centralized in a single system (the channel), all the engines with which it is connected depend of the same.
Channel Pull is usually accompanied by slower searches, since the engine must first send a request (Request), then wait for the response (Response), and once obtained, process it to show it to the client.
Another very common problem with Channels Pull is the possible loss of availability status, and the reason is very simple. All it takes is for the channel's servers to go down, for it to stop offering availability on all the engines with which it is connected, without anyone being able to do anything at all about it.
Lastly, and in my opinion the most important disadvantage of Channels Pull is their lack of flexibility. The hotel will have no choice but to limit itself to the functionalities offered by the channel. That the channel does not accept the promocode option? Then it will be very difficult for your website's search engine to implement them. And so with everything.
Aspiring, as always, to continue building possible bridges of collaboration, something that involves trying to resolve limitations like the one we just described, at Paraty Tech we have developed an intermediate layer that intercepts the channel prices before displaying them, which allows us apply a different logic to them. Unfortunately, this is not always possible due to the security measures of this type of channels, which usually include a price check, and when submitting the reservation, it may be rejected if the price does not match. And even if this were not the case, the mere fact of having two logics loaded in different places increases the complexity of the system, something that clashes head-on with what constitutes the main strength of Channels Pull: its simplicity of configuration and simplicity of connection.
Channels Push
This type of channel keeps prices, restrictions, and availability up to date on the panels it connects to. Normally it communicates with the search engines every time there is a change (quota, price, etc.) or periodically, every certain time interval. That is, there are identical and parallel structures loaded in all systems that are interconnected.
For this reason, the different websites that are connected to a Channel Push will always offer availability, regardless of whether the channel may suffer a blackout, since the entire product will be preloaded (and updated until said blackout) in the other systems, that work independently of the channel.
Furthermore, the speed when it comes to showing availability on the different websites is much higher than that of Channels Pull, since it does not require any type of communication between both systems.
Finally, it will also offer greater flexibility, since having pre-loaded prices will allow you to incorporate sophisticated offers, create packages, use promo codes, implement rates with complicated structures, etc. All of this, whether the channel supports these functionalities or not.
But then, what are the drawbacks of a Channel Push? In short, fundamentally two. On the one hand, the initial configuration will involve more work due to the famous mappings, having parallel structures loaded on both sides, which requires a correlation between the different internal codes.
On the other hand, resolving incidents can be somewhat more tedious. Having prices loaded in multiple panels can make it difficult to pinpoint the exact point where the problem occurred by displaying the wrong price or wrong availability.
In this regard, and finally, at Paraty Tech we have implemented auditing software that allows us to recover the XML history sent by the Push Channels, and thus know the specific day and exact time in which we receive a price, restriction or quota.
